home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
MACD 5
/
MACD 5.bin
/
workbench
/
tools
/
czesc_3
/
run68017
/
run68017.readme
< prev
next >
Wrap
Text File
|
1993-01-10
|
16KB
|
365 lines
Program name: Run68017. An upgrade from Run68013
Written with: Profimat (AssemPro) assembler
Machine: Standard Amiga 500 with OS1.3, One floppy drive,1 MByte RAM
Author: Kamran Karimi
Source: Included
Run methode: From both WorkBench and Shell
What it does: Emulates 30.5 of the 68020 instructions with a 68000
By the way:
Program status:This program is semi-shareware meaning that I would like to
receive money, books or software if you use this program, but it is not
obligatory for poor Amiga users (I am one of them!).
I retain the CopyWrite to to the program including the source and the
executable form of it.
Directory contents:
Run68017
Run68017.s
Run68017.ReadMe
------------------------------------------------------------------------------
CONTENTS: Line #
Important Notes --------------------------------- 43
Emulated Instructions/addressing modes ---------- 53
The Story --------------------------------------- 116
Program Description ----------------------------- 153
Bugs/Limitations -------------------------------- 207
Compatibility ----------------------------------- 248
Bug Reports ------------------------------------- 276
Next Version ------------------------------------ 291
Finally ----------------------------------------- 324
Important Note:
As I don't own an Amiga with a 68020 or higher processor, it is only natural
that not much testing has been done about the correct workings of the program.
My interpretations of the contents of the books have been my main guide to
the way the 68020 instructions and addressing modes should work,and these
interpretations may be quite wrong. This means That I can not guarantee the
correct workings of the program. It also means that I should rely a great
deal on fellow Amiga users to send me bug reports.
------------------------------------------------------------------------------
Emulated Instructions/addressing modes:
The new 68020 addressing modes emulated by this program are
1) (bd,An,Xn.size*Scale)
2) ([bd,An],Xn.size*Scale,od)
3) ([bd,An,Xn.size*Scale],od)
4) (bd,PC,Xn.size*Scale)
5) ([bd,PC],Xn.size*Scale,od)
6) ([bd,PC,Xn.size*Scale],od)
bd=Base Displacement ,An=an address register ,Xn=Index register
od=Outer Displacement ,PC=Program Counter
------------------------------------------------------------------------------
The 68020 instructions that are recognized by the program are
1) Bcc.l <label> (!)
2) BFCHG <ea>{offset:width}
3) BFCLR <ea>{offset:width}
4) BFEXTS <ea>{offset:width},Dn
5) BFEXTU <ea>{offset:width},Dn
6) BFFFO <ea>{offset:width},Dn
7) BFINS Dn,<ea>{offset:width}
8) BFSET <ea>{offset:width}
9) BFTST <ea>{offset:width}
10) BRA.L <label>
11) BSR.L <label>
12) CAS.x Dc,Du,<ea>
13) CAS2.x Dc1:dc2,Du1,Du2,(Rn1):(Rn2)
14) CHK.L <ea>,Dn
15) CHK2.x <ea>,Rn
16) CMP2.x <ea>,Rn
17) DIVS.l <ea>,Dq ;DIVS.l <ea>,Dr:Dq
18) DIVSL.L <ea>,Dr:Dq
19) DIVU.l <ea>,Dq ;DIVU.l <ea>,Dr:Dq
20) DIVUL.L <ea>,Dr:Dq
21) EXTB.L Dn
22) LINK.L An,#<data>
23) MOVE CCR,<ea>
24) MOVEC Rn,Rc ;MOVEC Rc,Rn
25) MOVES.x Rn,<ea> ;MOVES.x <ea>,Rn
26) MULS.l <ea>,Dl ;MULS.l <ea>,Dh:Dl
27) MULU.l <ea>,Dl ;MULU.l <ea>,Dh:Dl
28) PACK Dn,Dm,#<data> ;PACK -(An),-(Am),#<data>
29) RTD #<data>
30) TRAPcc ;TRAPcc #<data>
31) UNPK Dn,Dm,#<data> ;UNPK -(An),-(Am),#<data>
Rn=any general register, Dn=any data register, An=any addrress register
Rc=any control register,<ea>=an effective address, #<data>=immediate data
(!) Bcc.l is emulated only if the branch is taken!
Bra.l,Bcc.l and BSR.l cause an address error exception, other instructions
cause illegal instruction exception.
Refer to an appropriate book for more information about these instructions
and addressing modes.
------------------------------------------------------------------------------
The Story:
I began to write a software emulation program some time ago, after reading
about 68010 in a book.From that time I have continued to enhance the program
gradually. This is the third public release of the program and is a major
update to the previous version, Run68013. Main changes to the previous version
are:
More instruction are emulated.
The emulated instructions can use new 68020 addressing modes.
The program supports single stepping.
A number of bugs which I found have been removed and some parts have been
rewritten or otherwise changed to produce (I hope) better code.
Some may say that producing such programs is useless, because the prices
of 32 bit motorola processores are not very high and most people can afford
them. This is in fact true, but I believe there are always people whith
restricted budgets. On the other hand writing a program of this kind taught
me some good lessens (among them the fact that how hard it is to enhance a
badly written program!). I really hope it will be helpful to some Amiga Users.
To tell the truth, what worried me very much during the time I was writing
Run680XX was to hear that Motorola has ceased production of the 68000!.
I completed writing this version of the program short after I sent Run68013
to Fred Fish, but decided not to release it publicly until I could test the
program. Unfortunately Commodore representatives in Iran do not import Amigas
with 32 bit CPUs, so access to these processors is very hard for Amiga users.
On the other hand Apple representatives are very active and at the same time
very friendly. I went to one of them and asked if they could help me, and they
could!, so I took my Amiga there and put it beside a Mac II si. After writing
a short test program, I started to execute the same program on both machines
line by line and compare the results obtained from the emulator and the 68030.
Unfortunately I had not enough time, but it was possible to use some of the
instructions and see their effects in practice.
------------------------------------------------------------------------------
Program Description:
The program does the following when executed the first time:
It tests the EXECBase structure to see if it reports a 68000 or 68010 CPU,If
the program does not find any of them, then it will show a requester and quit
without doing anything.Memory is allocated and emulation routines are copied
there.After that a window opens showing some information about the program.
A message port is set up to indicate the presence of the program.This will
help to prevent running muliple copies of the program.
Based of the command line parameters the program may copy the address of the
emulation routines at the illegal instruction and address error exception
vectors and a window may open showing the current active 'processor'.
One can install or remove the emulation routines by a click in the
'CHANGE CPU' gadget. Quitting the program when the processor is '68017' ,will
let the emulation routine to stay in memory.Then only a reset will remove it.
Quitting when the processor is 68000 will remove every thing.
When run from the SHELL, one can enter one of the two arguments, like this:
1> run Run68017 68k
or
1> run Run68017 quit
the arguments are not case sensetive. '68k' will prevent the program from
installing the routines and the processor will remain the 68000. 'quit' will
instruct the program to install the routine and then quit.After that only a
reset will remove the installed routine.Only one of the two arguments can be
enterd because giving both at the same time is senseless. So the program
considers the first argument if several are provided on the command line.
When an illegal instruction or address error exception is encountered the
routine tries to identify the instruction causing the problem and if it is one
of the emulated instructions, it is emulated using self modifying code (Thank
you Von Neumann Architecture! you let code and data be considered the same).
The address of the next instruction is obtained and is used to replace the
address of the instruction that caused the exception.If the trace bit was set
before the exception happened, the address of the trace exception and the
status register (with the supervisor bit set and the trace bit reset) are put
on the stack, then an rte is used to transfer the control to the trace
exception handling routine.
As the emulation code is not reentrant, multitasking is disabled during the
emulation.
If non of the emulated instructions are recognized, the program places the
original exception handler routine and status register (with the supervisor
bit set and the trace bit reset) on the stack then an rte is executed to
transfer control to the original exception handler.
------------------------------------------------------------------------------
Bugs/Limitations:
Here are the known limitations/bugs in the program and explanations about
some of the routines:
* Only the emulated instructions can use new 68020 addressing modes.
In Bcc.l instruction:
* If the branch is not taken, the 68000 will 'execute' the displacement value
after the op-code.The results are unpredictable.
In MOVEC instrcuction:
* Executing this instruction in user mode causes a privilage violation.
* All the 68020 control registers are simulated by memory locations
* Both the MSP and ISP are interpreted as SSP.
* Before writing something in the MSP or ISP,make sure at least 12 bytes are
available below the new stack value because 12 bytes may be written in the
new satck pointer before returning to the main program.
* Writting a value in A7 register won't have any effect.
* If a value other than zero is copied in VBR, 1KByte of memory starting at
the new contents of the VBR are copied to the first KByte of memory to
ensure the use of proper vectores.
In MOVES.x instruction:
* Executing this instruction in user mode causes a privilage violation.
* No interpretation of the contents of the DFC or SFC are made during the move
* Writting a value in A7 register won't have any effect.
The CAS and CAS2 instruction:
* Are ofcourse not indivisible.
------------------------------------------------------------------------------
Compatibility:
A software emulater can not make up for the weaknesses in the hardware (like
a narrower Data/Address Bus, or the absence of Cache memory).
There is not much more that can be added to an emulation program like this,
which is based on "exception processing, rather than examining the code to be
emulated line by line". The advantage is more speed and the disadvantage is
that the emulation won't be %100.
Unfortunately the old 68000 instructions, when using 68020 addressing modes,
don't cause an exception, so this program can not emulate them.This means that
with a very high probability, most real world programs needing an MC68020
won't be able to run using this emulator.Most compilers DO produce code that
use new addressing modes. But the interested user can use this software to
enbable him/herself to become more aquainted with 68020/030/040 capabilities
without investing in an accelerator card. This is my main reason of writing
this code.
Running a program witch uses new addressing modes for older instructions will
cause unpredictable results, based on the interpretations of the instruction
extension words by the good old 68000!.Most probably you'll visit MR. GURU!.
Note that using this software not only does not bring any speed advantages,
but depending on the frequency of encountering the instructions to be
emulated, you'll have an speed reduction, though it would be negligible.
------------------------------------------------------------------------------
Bug Reports:
It would be very helpful if I could receive bug reports from you. When
encountering a bug, please write enough information to make it possible to
track the bug. Write what happened when you found the bug ( GURU, HangUp or
what ever). Among the things that would help in debugging, beside the
instruction that cuaed the problem, are the CPU registers just before the
problem occured and status register contents.
It would be nice if some one with access to both a 68000 and 68020 (or
higher) processors would take the trouble and write a test program to compare
the hardware CPU and the emulator.
------------------------------------------------------------------------------
Next Version:
Logically the next version of the program should be a bug-fix, but only if I
could find out the bugs!.
As you read earlier, not much more can be done about the emulation if we rely
on exception processing only, because there are few other things that cause an
exception. To overcome this inherent problem I first thought that it would be
possible to read an executable file, find instructions that use new addressing
modes, change the relative bits to show an illegal addressing mode, and then
execute the program. This program already emulates 68020 addressing modes and
it needs little effort to handle old instructions to use them as well.So we'll
have a complete 68020 emulator.
But the problem is that in this way one should follow the execution flow as
the processor does when the program is run, this is because we don't have a
way to find out what is an instruction and what is data (Damn you Von Neumann
Architecture!).This would be a semi 'Compiler' for translating 68020 code to
68000.But I think it is not worth the effort because we are forced to produce
a 68000 emulator before proceeding!. Any body has any suggestions regarding
this approach?.
The other thing we can do is to make an 'Interpreter'.In this way the program
that containes 68020 specific instructions/addressing modes is loaded in
memory and the address of its first instruction is obtained. Then it is put in
single step and we examine the instruction to be executed after the previous
one has been executed. If a new addressing mode is found then it is simulated
and program continues with the next instruction.To do this, I need to know how
we can load a program to memory, obtain its first instruction and set the
single step bit for it, much like the thing that all debuggers do.Please write
to me if you can help in this area. I don't have any access to information
about DOS library and other related material like segments, hunks and so on.
------------------------------------------------------------------------------
Finally:
The code has been written and assembled with Profimat (AssemPro), but it
should also do well with other assemblers, as few profimat-specific features
have been used.
I have not tested the program under any other OS version or CPU. Maybe some
one will do so and kindly let me know about the results.
You have lots of options for paying for the program:
1) Explain how debuggers work, that is, how they load a program from disk
to memory and place it in single step, allowing it to be executed line by line
also, how we can find out that the program under debugging has actually ended
(or putting it another way, how to find out that which rts is the last one in
the program code?).
2) Send a small donnation.
3) Send me computer books (especially Amiga books), Software or manuals you
don't need any more, or even photocopies of articles in books or magazines
containing Amiga programming guides or examples.
Here in Iran I have not much access to information on the Amiga so I would
appreciate receiving technical information in any form.
4) Send me bug reports and mention the weak points of the program and the ways
to improve it.My main reason of writing programs is to learn more.
Send any bugs you find or any suggestions or donnations to
Kamran Karimi
2,Hassanabad
Haghshenas str.
Navab str.
13599 - Tehran
Iran